浅谈Linux cgroup机制与YARN的CPU资源隔离

大数据技术与架构点击右侧关注，大数据开发领域最强公众号！

暴走大数据点击右侧关注，暴走大数据！

前言

我们在生产环境中经常可以发现有计算密集型任务争用NodeManager的CPU，以及个别Container消耗太多CPU资源导致其他系统服务抖动的情况。好在Hadoop 2.2版本之后，YARN通过利用Linux系统的cgroup机制支持了CPU资源隔离。本文先简单看看cgroup，然后分析一下YARN的CPU资源隔离的方案。

简单入门cgroup

cgroup（control group）机制在Linux Kernel 2.6.24引入，主要用来限制与隔离进程组的资源——包括CPU、内存、磁盘、网络等，也可以用于控制优先级、统计资源用量、挂起与恢复进程。

从用户的角度看，一个cgroup就是一组按某种资源控制的标准划分的进程（task）。cgroup被组织成树形结构，称为层级（hierarchy），使得子cgroup可以继承父cgroup的部分控制属性。同时每个层级又会与一个或多个子系统（subsystem）关联，子系统会在该层级的所有树节点上执行具体的资源控制操作。也就是说，子系统实际扮演着资源控制器的角色。

内核为每种资源都定义了子系统，功能各自不同，举例如下。

• cpu子系统：限制进程的CPU使用率；

• cpuacct子系统：统计进程的CPU使用报告；

• cpuset子系统：将进程绑定到指定的CPU或内存节点；

• memory子系统：限制进程的内存使用率，并统计进程的内存使用报告；

• blkio子系统：限制进程的块设备I/O速率；

• devices子系统：指定进程可以访问哪些设备；

• net_cls子系统：标记进程收发的数据包，进而用tc限制网络流量。

下图示出有两个层级的cgroup结构，其中层级A关联了cpu和memory两个子系统，层级B关联了net_cls子系统。注意图中的红色小叉，它表示同一个进程可以属于不同的层级，但是不能同时属于同一个层级的两个cgroup。

为了方便用户操作，cgroup通过VFS向用户提供文件系统接口（如同/proc一样）。执行mount -t cgroup命令可以查看已挂载的cgroup对应各个子系统的目录。这里系统版本是CentOS 7，cgroup的根目录是/sys/fs/cgroup；CentOS 6则是/cgroup。

~ mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)

cgroup的CPU子系统

在CPU子系统的根目录下创建一个新的cgroup目录，会自动生成一些文件。

~ cd /sys/fs/cgroup/cpu
~ mkdir cg_test
~ ls -1 cg_test
cgroup.clone_children
cgroup.event_control
cgroup.procs
cpuacct.stat
cpuacct.usage
cpuacct.usage_percpu
cpu.cfs_period_us
cpu.cfs_quota_us
cpu.rt_period_us
cpu.rt_runtime_us
cpu.shares
cpu.stat
notify_on_release
tasks

最主要的几个文件及它们的含义列举如下。

• tasks
  保存有该cgroup内包含的PID列表，可以动态增减。

• cpu.cfs_period_us
  表示CPU时间片的调度周期，单位为微秒，默认值100000（即100毫秒）。其中CFS一词代表"Completely Fair Scheduler"，即内核中的完全公平进程调度器。

• cpu.cfs_quota_us
  表示给这个cgroup里的进程分配的CPU时间片的长度，单位为微秒，默认值-1（即不限制）。举个例子，如果cpu.cfs_period_us=100000，且cpu.cfs_quota_us=200000，就表示该cgroup的进程最多可以使用200%的CPU；如果cpu.cfs_quota_us=50000，就表示最多可以使用50%的CPU。

• cpu.shares
  表示cgroup内进程占用CPU权重的相对比例，默认值1024。举个例子，组A的cpu.shares=1024，组B的cpu.shares=2048，那么当两个cgroup中的进程都满负载运行时，组B能占用的CPU资源就是组A的两倍。如果有一方负载较低时，另一方还可以利用空闲的CPU资源。可见，它是比上述两个参数更为弹性化的限制。

• cpu.stat
  保存有该cgroup的CPU资源的统计信息，包含cgroup创建开始经过的CPU周期，以及被cgroup限制掉的CPU周期和时间长度。

cgroup的层级关系就靠目录结构表示。如果我们在cg_test目录下再新建cg_test_sub1、cg_test_sub2目录，那么这两个cgroup就是cg_test的子节点，以此类推。

来操作一下吧。先用Python跑一个死循环，然后top之，发现该进程占用100%的CPU。

~ echo 'while True: pass' | python &
[1] 15054
~ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
15054 root      20   0  123356   4476   1952 R 100.0  0.0   0:14.74 python

然后将刚才创建的cg_test组的cpu.cfs_quota_us值改为30000，并将该进程的PID写入tasks，再top之，就会看到它的CPU占用降低到了30%。

~ echo 30000 > /sys/fs/cgroup/cpu/cg_test/cpu.cfs_quota_us
~ echo 15054 > /sys/fs/cgroup/cpu/cg_test/tasks
~ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
15054 root      20   0  123356   4476   1952 R  29.9  0.0   1:54.17 python

YARN CPU资源隔离实现

要启用YARN的CPU资源隔离，就得在yarn-site.xml里设定以下两个参数。更加详细的设定（如cgroup层级和路径等）请参考官方文档。

yarn.nodemanager.container-executor.class: org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor
yarn.nodemanager.linux-container-executor.resources-handler.class: org.apache.hadoop.yarn.server.nodemanager.util.CgroupsLCEResourcesHandler

我们需要使用LinuxContainerExecutor来替代默认的DefaultContainerExecutor，因为前者会以YARN App提交者的身份执行创建和销毁Container的动作，并且支持cgroup机制。另外，还需要配置与它配套的支持cgroup的资源处理器类，即CgroupsLCEResourcesHandler。

接下来翻翻源码。在启动Container的LinuxContainerExecutor.launchContainer()方法中，调用了CgroupsLCEResourcesHandler.preExecute()方法初始化资源限制。

  public void preExecute(ContainerId containerId, Resource containerResource)
              throws IOException {
    setupLimits(containerId, containerResource);
  }

  private void setupLimits(ContainerId containerId,
                           Resource containerResource) throws IOException {
    String containerName = containerId.toString();

    if (isCpuWeightEnabled()) {
      int containerVCores = containerResource.getVirtualCores();
      createCgroup(CONTROLLER_CPU, containerName);
      int cpuShares = CPU_DEFAULT_WEIGHT * containerVCores;
      updateCgroup(CONTROLLER_CPU, containerName, "shares",
          String.valueOf(cpuShares));
      if (strictResourceUsageMode) {
        int nodeVCores =
            conf.getInt(YarnConfiguration.NM_VCORES,
              YarnConfiguration.DEFAULT_NM_VCORES);
        if (nodeVCores != containerVCores) {
          float containerCPU =
              (containerVCores * yarnProcessors) / (float) nodeVCores;
          int[] limits = getOverallLimits(containerCPU);
          updateCgroup(CONTROLLER_CPU, containerName, CPU_PERIOD_US,
            String.valueOf(limits[0]));
          updateCgroup(CONTROLLER_CPU, containerName, CPU_QUOTA_US,
            String.valueOf(limits[1]));
        }
      }
    }
  }

setupLimits()方法首先将单个Container申请的虚拟核心数记为containerVCores，然后调用createCgroup()方法创建包含Container名称的cgroup文件目录，也就是说一个Container对应一个cgroup。然后根据containerVCores设定这个cgroup的cpu.shares值（乘以默认值1024），即申请核心数越多，可占用的CPU资源比例越大。

接下来检查yarn.nodemanager.resource.percentage-physical-cpu-limit参数是否为true。若为true，表示启用了严格限制模式，需要设置cpu.cfs_period_us和cpu.cfs_quota_us。

使用containerVCores * yarnProcessors / nodeVCores推导出单个Container对应的物理核心数，其中yarnProcessors表示NodeManager所在节点的可用物理核心数（即总核心数乘以参数yarn.nodemanager.resource.percentage-physical-cpu-limit指定的百分比比例），nodeVCores表示单个NodeManager的虚拟核心数。

最后就是getOverallLimits()方法了。

  int[] getOverallLimits(float yarnProcessors) {

    int[] ret = new int[2];

    if (yarnProcessors < 0.01f) {
      throw new IllegalArgumentException("Number of processors can't be <= 0.");
    }

    int quotaUS = MAX_QUOTA_US;
    int periodUS = (int) (MAX_QUOTA_US / yarnProcessors);
    if (yarnProcessors < 1.0f) {
      periodUS = MAX_QUOTA_US;
      quotaUS = (int) (periodUS * yarnProcessors);
      if (quotaUS < MIN_PERIOD_US) {
        LOG
          .warn("The quota calculated for the cgroup was too low. The minimum value is "
              + MIN_PERIOD_US + ", calculated value is " + quotaUS
              + ". Setting quota to minimum value.");
        quotaUS = MIN_PERIOD_US;
      }
    }

    // cfs_period_us can't be less than 1000 microseconds
    // if the value of periodUS is less than 1000, we can't really use cgroups
    // to limit cpu
    if (periodUS < MIN_PERIOD_US) {
      LOG
        .warn("The period calculated for the cgroup was too low. The minimum value is "
            + MIN_PERIOD_US + ", calculated value is " + periodUS
            + ". Using all available CPU.");
      periodUS = MAX_QUOTA_US;
      quotaUS = -1;
    }

    ret[0] = periodUS;
    ret[1] = quotaUS;
    return ret;
  }

可见，YARN采用了固定cpu.cfs_quota_us值（为1000000，即1秒），而改变cpu.cfs_period_us值的方式。cpu.cfs_period_us的值恰好是cpu.cfs_quota_us除以上面计算出来的单个Container对应的物理核心数，所以核心数越多的Container，cpu.cfs_period_us越小，可利用的CPU资源就越多。

最后再举个例子。假设NodeManager可用物理核心数为4（即总CPU资源为400%），虚拟核心数为6，根据上述算法，考虑3种情况。

• 启动4个Container，每个Container申请1*vCore——普通模式每个Container分配100%，严格模式每个Container分配67%；

• 启动2个Container，A申请2*vCore，B申请1*vCore——普通模式为A分配200%，B分配100%，严格模式为A分配133%，B分配67%。

• 启动4个Container，A组两个申请2*vCore，B组两个申请1*vCore——两种模式均为为A组分配133%，B分配67%。

由上面的分析我们可以看出，cpu.share方式相当于"soft limit"，用于控制Container使用CPU资源的下限，并且更加灵活，总体资源利用率高，但无法完全避免不稳定因素。而cpu.cfs_period_us+cfs_quota_us方式相当于"hard limit"，严格限制了Container使用CPU资源的上限，显然更加稳定，但是在低负载的场景下，CPU资源就会被浪费，鱼与熊掌不可兼得。

——END——

文章不错？点个【在看】吧！ 👇